Switch push created repo to ContainerRepository#2366
Conversation
gerrod3
force-pushed
the
push-no-more
branch
2 times, most recently
from
6a9693a to
ed996a1
Compare
https://redhat.atlassian.net/browse/PULP-1748 Assisted by: cursor composer 2
Treat registry-pushed container repositories like push repos when signing, allow legacy push repo fixtures without a distribution, clean up test distributions, and update RBAC content expectations for repository viewers. Co-authored-by: Cursor <cursoragent@cursor.com>
Match ContainerPushRepository permission checks when scoping content queries by repository_version on registry-pushed container repositories. Co-authored-by: Cursor <cursoragent@cursor.com>
Model-level view_containerdistribution must not grant repository_version filtering on synced container repositories that have a remote. Co-authored-by: Cursor <cursoragent@cursor.com>
Distribution consumers may only filter content by repository_version on container repositories that have no remote and are tied to a distribution. Co-authored-by: Cursor <cursoragent@cursor.com>
Exclude push-created container repositories from mirror-scoped tag access so distribution permissions govern that content instead. Co-authored-by: Cursor <cursoragent@cursor.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
…ies to be consistent
| ) | ||
| ns_repository_pks = models.ContainerDistribution.objects.filter( | ||
| namespace__in=namespaces, | ||
| pulp_domain=domain, |
There was a problem hiding this comment.
Completely unrelated to this PR, but it would be nice if we could make have queries automatically detect domain from a context var and filter based on that domain. It's tedious and error prone to have to include the domain in every query. Maybe there's an ORM middleware for that.
|
|
||
| #### `docker/podman push` | ||
|
|
||
| When pushing an image to Pulp there are three different scenarios a user can find themselves in which determines the permissions that are checked for during the push. |
There was a problem hiding this comment.
This section is a bit too indirect and can be made more straightforwards. I would also maybe reverse the order of the scenarios if you're going to talk about scenario 3 first.
|
|
||
| #### `docker/podman pull` | ||
|
|
||
| When pulling an image Pulp will check the `pull` action on the Container Distribution access policy. |
There was a problem hiding this comment.
Is it correct to say that all users must have a Pulp user in order to pull content? I was trying to figure out what direction to go in with the pulp_rust plugin, since the normal protocol is that each user is assigned a secret API token which is then used for auth, but strictly speaking auth could probably go through the Pulp user permissions / RBAC system.
There was a problem hiding this comment.
No, the pull action checks to see if the distribution is not private first, if it is "public" then any user, authenticated or not, can pull the image. If the distro is private then the user needs to be logged in as Pulp user.
| ##### Push to a new namespace | ||
|
|
||
| Let's start with Scenario 3 which requires the least amount of permissions and only checks the `push` action on the Container Distribution access policy. | ||
| If the namespace does not exist, Pulp checks the `create` action on the Namespace access policy. The user needs `container.add_containernamespace`, or the namespace name must match their username. On success, they are granted the Namespace *Owner* role for the new namespace, which in turn grants them permission to create the distribution for the new image. |
There was a problem hiding this comment.
The user needs
container.add_containernamespace, or the namespace name must match their username.
Does this mean that users could create a namespace that matches a different username?
There was a problem hiding this comment.
Yes if they have the Namespace creator role or are admin.
2 participants
https://redhat.atlassian.net/browse/PULP-1748
Assisted by: cursor composer 2
📜 Checklist
See: Pull Request Walkthrough